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ABSTRACT 

Evolving  requirements  including  the  development  of  the 
Joint  Operation  Planning  and  Execution  System  (JOPES)  are 
forcing  the  WWMCCS  ADP  community  toward  the  development  of  a 
distributed  data  base  approach  to  information  management.   In 
this  thesis  the  Electronic  Data  Interchange  (EDI)  concept  is 
examined  as  a  proposed  system  for  realizing  a  distributed 
data  approach.   Using  the  EDI  concept,  any  command  which  could 
translate  to  and  from  the  EDI  standard  data  set  could  exchange 
data  with  any  other  participating  command.   Implementation  of 
this  sort  of  system  would  facilitate  interfaces  among  commands 
while  not  limiting  participating  commands  to  specific  hardware, 
software,  or  data  base  management  systems.   The  thesis  proposes 
the  EDI  concept  as  a  step  toward  realization  of  better  data 
distribution  and  management  in  WWMCCS  ADP. 
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I-  INTRODUCTION 

In  the  Worldwide  Military  Command  and  Control  System 
(WWMCCS)  current  ADP  capabilities  do  not  provide  sufficient 
support  for  the  exchange  of  data  among  commands  in  a  timely 
and  effective  manner.  In  order  to  exchange  data  tcdayf 
generally,  commands  must  have  the  same  hardware  and  soft- 
ware. In  some  other  cases  specific  software  must  also  be 
developed  to  exchange  and  translate  data  between  applica- 
tions which  are  interfaced.  These  conditions  cause 
inefficient  use  of  resources  and  severely  limit  capabilities 
to  respond  to  command  and  control  requirements. 

Evolving  requirements  including  the  development  of  the 
Joint  Operation  Planning  and  Execution  System  (JOPES)  are 
forcing  the  WWMCCS  ADP  community  toward  the  development  of  a 
distributed  data  base  approach  to  information  management. 
In  this  thesis  the  Electronic  Data  Interchange  (EDI)  concept 
is  examined  as  a  proposed  system  for  realizing  a  distriruted 
data  approach. 


"The  U.  S.  Electicnic  Data  Interchange  (EDI)  Standards 
are  designed  to  facilitate  the  electronic  interchange  of 
data  in  a  standard  manner  between  independently  organ- 
ized, cwned,  and/cr  operated  computer  and  communication 
systems.  .  .  The  EDI  standards  grew  from  needs  in 
transportation  andpayment  applications  and  have  teen 
extended  for  use  in  other  business  and  technical  appli- 
cations." [  Bef.  1:   p.  6  ] 


Implementation  of  this  sort  of  system  would  facilitate 
interfaces  among  commands  while  not  limiting  participating 
commands  to  s-pecific  hardware,  software,  or  data  base 
management  systems. 


Chapter  II  of  the  thesis  provides  background  by  defining 
WWMCCS,  and  WWMCCS  ADP,  and  explains  the  current  approach  to 
WWMCCS  ACE  management.  Chapter  III  discusses  the  problems 
of  data  management  in  conventional  planning  and  execution. 
In  this  chapter  specific  problems  are  identified  along  with 
documented  requiements  which  cannot  be  satisfied  using  the 
current  procedures.  Chapter  IV,  Recommendations,  includes 
some  background  on  current  capabilities  in  ADP  which  could 
be    exploited  for      better   command    and   control.  In    addition 

the  Electronic  Data  Interchange  (EDI)  concept  is  examined  as 
a  proposed  system  for  meeting  evolving  WWMCCS  ADP  data 
management  requirements.  EDI  is  evaluated  in  its  potential 
to  alleviate  the  specific  problems  which  are  identified  in 
Chapter  III.  Chapter  V  provides  a  summary  of  how  the  EDI 
concept  could  help  improve  data  interchange  among  commands 
and   includes  an    illustration  of   an    EDI   application. 

The  thesis  proposes  the  EDI  concept  as  a  step  toward 
realization  of  better  data  distribution  and  management  in 
WWMCCS    ACF. 


II.  EACKGRCaND 

A.   WWMCCS  ADP  OBJECTIVES 

"The  WSflCCS  is  the  Worldwide  Military  Command  and 
Control  System  that  provides  the  means  for  operational 
direction  and  technical  administrative  support  involved  in 
the  function  of  command  and  control  of  United  States  mili- 
tary forces,"  [Ref.  2].   The  elements  of  WWMCCS  are; 

-  warning  systems 

-  communications 

-  command  facilities 

-  executive  aids 

-  data  collection  and  processing 

The  WWMCCS  ADP  System  includes  the  ADP  hardware,  system 
software,  application  software,  data  bases,  files,  proce- 
dures, data  management  system  (s),  related  personnel,  data 
communications  equipment,  and  circuits.  The  ADP  support  at 
the  Service  headquarters  and  Service  component  levels  may  be 
a  mix  of  both  WWMCCS  and  unique  systems. 


"The  WWMCCS  ADP  system  (s)  must  support  both  the  primarv 
and  secondary  missions  of  the  WWMCCS  as  stated  in  LOD 
Directive  5100.30  and  JCS  PUE  19.  In  doing  so,  the  ADP 
system  will  support  the  command  and  control  requirements 
of  the  National  Military  Command  System  (NMCS) ,  unified 
and  specified  comnands.  component  commands,  service 
headquarters,  subordinate  unified  commands,  JT'Fs,  TOAs. 
the  Joint  Deployment  Agency  (JDA)  ,  and  the  Joint 
Strategic  Target  Planning  Staff  (J3TPS) ,  and  related 
functions  of  other  defense  agencies.  Tne  svstem  must 
support  the  decisionmakers  and  their  staffs  by 
providing ; 

timely  and.   accurate  information  on  the  status  and 
location  of  forces  and  major  resources 

the  capability  to  develop  and  implement  both  conven- 
tional and  nuclear  operations  plans  and  options 


the  capability  tc  formulate  and  transmit  direction 
to  and  receive  and  assess  reports  from  the  appro- 
priate   commands    and   organizations 

the  capability  to  rapidly  and  securely  exchange 
information,  both  laterally  and  vertically,  across 
service    and    command    boundaries... 

In  general,  meeting  these  objectives  will  result  in  a 
capability  to  capture,  transmit,  and  process  information 
in  a  timely  and  accurate  fashion  and  to  display  useful 
and   easily  understccd   formats."      [Eef.    3:    p.   A-2] 


The  WWKCCS  ADP  Concept  of  Operations  and  General 
i?££Liii£§Ii!.£I!£§  for  ?gst2J.985  was  approved  by  the  JCS  and  the 
Services  in  1981.  The  documentation  identified  four  func- 
tional families  of  processing  requirements  within  WWMCCS 
ADP.  Most  WWMCCS  applications  software  and  data  bases  can 
be    grouped    into    one    cf   these   functional    families: 

-  Pesource  and  Unit   Monitoring    (RUM) 

-  Conventional  Planning   and    Execution     (CPE) 

-  Nuclear   Planning    and  Execution    (NPE) 

-  Tactical     Warning/Attack   Assessment   and      Space   Defense 
(TW/AA    and   SD) 

Conventional  Plarning  and  Execution  will  be  used  to 
illustrate  some  of  the  problems  wnich  can  result  when  there 
is  insufficient  provision  for  interfaces  among  data  bases. 
Conventional  Planning  and  Execution  (CPE)  generally  includes 
the  development,  maintenance,  and  execution  of  operation 
plans  for  the  deployment  and  employment  of  United  States 
military   forces.      CPE  includes: 

-  Generating    and    refining    operatonal    requirements 

-  Merging   requirements   from   different    plans 

-  Determining    oplan   feasibility 

-  Matching  requirements  with    actual   resources 

-  Developing    and    disseminating   schedules    and  orders 

-  Identifying    shortfalls    and    limitations 

-  Rapidly   reflowing    movement   requirements 
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-  Coordination  and  inonit  orin.g  mobilization  and  deploy- 
ments 

-  Aggregating  and  summarizing  requirements 

The  CPE  function  relies  heavily  on  ADP  support  espe- 
cially since  the  JCS  has  directed  that  the  Joint  Operational 
Planning  System  (JOPS)  be  used  in  planning  for  operations, 
force  deployment,  and  support  of  U.S.  Joint  Military 
Operations.  "The  JOES  consolidates  policies  and  procedures 
for  the  development,  coordination,  dissemination,  review  and 
approval  cf  joint  plans  for  the  conduct  of  military  opera- 
tions," [Eef.  4:  p.  3].  In  addition,  the  members  of  the 
Joint  Deployment  Community  (JDC) ,  which  includes  the  unified 
and  specified  commands,  component  commands,  Services,  TCAs 
and  JEA,  use  the  Joint  Deployment  System  in  support  of  oper- 
ation plan  execution  and  monitoring.  To  communicate  and 
coordinate  among  commands  in  support  of  CPE  the  NflMCCS 
Intercomputer  Network  (FIN)  is  used.  Many  command  and 
service  unique  software  applications  are  used  tc  prepare 
data  for  input  to  JOPS  and  JDS,  but  interfaces  among  these 
unique  applications  and  JOPS  and  JDS  are  for  the  most  part 
manual  as  is  the  interface  tetween  JOPS  and  JDS. 

B.   WKHCCS  ADP  MANAGEMENT 

The  management  approach  which  has  prevailed  in  WWMCC5 
ADP  has  teen  one  of  standardizing  software  as  well  as  hard- 
ware. Management  procedures  for  the  WWMCCS  standard  ADP 
system  are  promulgated  in  JCS  PUB  19.  The  procedures 
support  the  acquisition,  maintenance,  and  continued  improve- 
ment of  the  WWMCCS  standard  ADP  system  and  apply  to  its 
users.   Objectives  of  these  procedures  include: 

"reduce  the  duplication  of  effort  in  design,  develop- 
ment, acquisition,  and  maintenance  of  /JWMCCS  ADP 
hardware,  applicaticn  software,  and  system  software, 


1  1 


maximize  the  henefits  of  compatibility  and 
standardization  of  WWMCCS  ADP  hardware,  application 
software,  and  system  software,"  [ Ref .  5:   p.  11-14] 


C.   WWMCCS  ADP  STANDARD  APPLICATIONS  SOFTWARE 


11  Application  software  or  portions  thereof,  devel- 
oped within  a  command,  agency  or  Service  or  for  the 
Chairman,  Joint  Chiefs  of  Staff,  will  often  have 
applicability  to  like  command-level  WWMCCS  activi- 
ties or  the  other  command  levels  with  common 
requirements  or  similar  information  needs...  In 
particular  where  a  Service,  agency,  or  command  or 
the  Chairman,  Joint  Chiefs  of  Staff,  has  an  existina 
caoarilitv  to  perform  a  specific  technical  support 
task,  that  capability  will  be  utilized  to  the 
maximum  extent  feasible  rather  than  initiating  a 
separate  development  effort."   [Re£.  5,  p.  III-2] 


What  this  means  in  the  WWMCCS  ADP  community  is  that  an 
individual  command,  Service,  or  agency  is  assigned  as  the 
Designated  Responsible  Activity  (DRA)  for  development  and 
standardization  of  a  specific  application  which  has  been 
approved  as  a  standard.  The  OJCS  C3  Systems  Directorate 
maintains  cognizance  over  all  standard  systems  in  an  effort 
to  avoid  unnecessary  duplication  and  attempt  to  meet  a  broad 
spectrum  of  user  requirements. 

By  the  late  1980s,  this  "standard"  WWMCCS  ADP  with 
its  processors  and  associated  software  will  be  techno- 
logically obsolete,  operationally  archaic  and  difficult 
to  support  logistically.  (Modernization  will  require 
both  new  hardware  and  new  applications  software  and 
system  software)."   [Ref,  6:   p.  ES-1  ] 

Much  of  the  standard  applications  software  was  written 
originally  to  operate  in  a  batch  processing  environment 
which  makes  it-  inefficient  and  often  ineffective  for  crisis 
support  which  generally  requires  interactive  capability.  At 
present  a  data  base  must  be  resident  on  the  same  computer  as 
the  executing  application.   This  means  that  every  site  using 
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an  application  mast  have  access  to  copies  of  the  relevent 
softvare  and  data  base  on  the  system  on  which  the  processing 
will  te  done.  Hany  commands  have  modified  their  copies  of 
the  standard  applications  to  better  suit  their  unique 
requirements  so  that  it  is  actually  no  longer  the  standard 
application  software. 
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.Si.  0^  Ko  ^  oJs  , 


III.     PROBLEMS 


A.   TBI  CPE  ENVIRONMENT 

1 .   Elanninq 

The  JCS  has  directed  that  the  Joint  Operation 
Planning  System  (JGPS)  will  te  used  in  planning  for  opera- 
tions, force  deployment,  and  support  of  US  joint  military 
operations.  JOPS  supports  planning  under  time-sensitive  or 
crisis  conditions  with  procedures  wnich  form  the  Crisis 
Action  System  (CAS) .  Under  non-crisis,  peacetime  situations 
JOPS    is   employed   in    the   deliberate   planning   process. 

a.      Deliberate   Planning 

Deliberate  planning  consists  of  five  phases 
which   are   outlined    in   Figure   3.1   [fief,    4:      p.    3] 

The  majcr  product  created  during  the  plan  development  phase 
cf  JOPS  is  the  time-phased  force  deployment  data  (TPFDD) . 
When  planning  is  complete,  the  TPFDD  contains  all  of  the 
information  needed  tc  describe  a  deployment.  TPFDD  refine- 
ment is  conducted  in  a  two-phase  conference  hosted  by  the 
Joint   Deployment   Agency    (JDA)  . 

The  WIN  is  utilized  as  a  timely,  secure  means  of 
distributing  data  to  the  deployment  community  to  facilitate 
the  refinement  process.  Prior  to  the  Phase  I  refinement 
conference  the  WIN  is  used  to  distribute  the  unrefined 
TPFDD,  which  contains  only  notional  data,  to  the  deployment 
community  in  order  that  initial  analysis  can  be  conducted 
prior  to  the  conference.  During  the  Phase  I  conference  as 
actual  forces  are  designated  to  replace  the  notional  forces 
in  the  TEFDD  and  transportation  requirements  are  identified, 
the      TPFDD        is      updated      to        reflect      these        changes      and 
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Figure    3.1        Deliberate   Planning. 

distributed   to      the    TOAs.  Each  of      the    TOAs      uses   command 

unique  applications  software  to  prepare  movement  schedules 
supporting  the  requirements  in  the  TPFDD  and  to  check  the 
resulting  schedules  for  feasibility  of  execution,  identif- 
ying shortfalls  (requirements  which  cannot  be  met) . 
Military  Airlift  Command  (MAC)  forwards  the  TPFDD  by  WIN  to 
Military  Traffic  Management  Command  (MTMC)  after  identifying 
airlift    in     support    cf      the    plan   and      checking  the      plan    for 
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feasibility.  As  the  provider  for  ground  transportation  and 
transportation  within  the  continental  United  States,  MTMC 
identifies  and  tests  for  feasibility  the  transportation 
support  to  te  provided  by  MTMC.  The  WIN  is  used  again  to 
forward  the  TPFDD  tc  Military  Sealift  Command  (MSC) .  The 
sealift  support  for  the  plan  is  identified,  as  well  as  the 
resulting  shortfalls,  and  the  TPFDD  ,  with  air,  ground,  and 
sea  transportation  identified,  is  forwarded  by  WIN  to  the 
Joint  Deployment  Agency.  In  addition,  the  modified  TPFDD  is 
distributed  to  the  deployment  community  for  review  of  short- 
falls pricr  to  the  Phase  II  conference.  During  Phase  II  of 
the  refinement  process  as  shortfalls  are  studied  the  plan  is 
modified  tc  resolve  the  shortfalls,  resulting  in  the 
requirement  for  reflcwing  the  transportation  support. 

When  the  TPFDD  has  been  refined  and  the 
resulting  CPLAN  reviewed  and  approved  by  the  Joint  Chiefs  of 
Staff,  it  is  then  entered  into  the  deployment  data  base  at 
JDA  and  is  accessible  to  the  deployment  community  by  means 
of  the  WIN. 

b.   Plan  Maintenance 

An  ongoing  teleconference  is  maintained  for  each  approved 
OPLAN  in  order  to  provide  a  forum  for  discussing  changes 
required  to  maintain  and  update  tne  plans. 

Usually  the  first  15  days  of  airlift  and  the  first  30 
days  of  sealift  are  reviewed  by  the  appropriate  members 
of  the  Jcint  Deployment  Community,  wno  verify  that  the 
units  and  material  designated  in  the  plan  are  actually 
available,  and  would  most  likely  be  the  ones  used, 
should  the  plan  be  executed...  upon  completion  of  the 
maintenance  cycle,  the  revised  data  replaces  the 
outdated  requirements  in  the  Joint  Deployment  System 
(JDS)  ,  [Bef.  7:   p.  13]. 

This  review  is  usually  conducted  quarterly. 


16 


c.      Time-sensitive    Planning 

The  Crisis  Action  System  (CAS)  which  is  utilized 
for  time-sensitive  planning  has  six  phases  as  illustrated  in 
Figure   3.2    [Ref.    4:      p.    7]. 

In    the   situation   development   phase  commanders 
can    use   the  WIN    to      submit    Operational   Reports    (OPREPS)      to 
appropriate   authorities.         CPREP    messages   are   used   to   commu- 
nicate  concerning   incidents    or   conditions   which    could    evolve 
into    a   crisis. 

In  the  crisis  assesment  phase  Will  is  used  to 
conduct  a  teleconference  in  which  representatives  from  the 
NMCC ,  the  Service  headquarters,  the  Unified  and  Specified 
Commands,    the   JDA,    and   the    lOAs    participate. 
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In  the  course  of  action  development  phase  the 
WIN  is  utilized  as  the  transmission  mode  for  the  OPEEP-1 
messages  used  to  exchange  required  information.  Using  CPEEP 
messages  on  the  WIN,  JCS  promulgates  a  warning  order,  the 
supported  commander  then  tasks  the  deployment  community  for 
required  assistance  in  developing  or  revising  plans.  The 
depolyment  community  in  turn  forwards  responses  and  the  JDA 
updates  the  JDS  data  base  for  the  plan  being  developed  or 
modified. 

In  the  execution  planning  phase  WIN  is  used  for 
transmission  of  the  alert  order  and  operation  order.  The 
deployment  community  develops  supporting  operation  orders  as 
required  and  uses  WIN  to  forward  updated  information  to  JDA 
for  inclusion  in  the  JDS  data  tase. 

2 .   Execution 

"The  Joint  Deployment  System  supports  deployment  execu- 
tion and  sustainment  of  f orces. . .After  the  JCS  execute 
order,  the  JDS  must  monitor  status  of  deploying  forces, 
material,  and  non-unit  related  personnel. .. JDA  must  also 
be  able  tc  rapidly  respond  to  changes  in  the  deployment 
as  execution  processes."   [Ref.  7:   p.  16] 

The  JDS  capabilities  supported  by  WIN,  which  are 
available  tc  the  joint  deployment  community  during  deploy- 
ment execution  are: 


-  A  teleconference  is  used  to  exchange  textual  informa- 
tion among  the  members  of  the  deployment  community  to 
assist  in  decision  naJcing. 

-  Access  to  the  JDS  data  base  is  available  by  one  of  the 
following  means: 
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Direct  access  to  the  JDS  data  base  is 
possible  using  WIN  to  access  the  timesharing 
subsystem  of  the  JDA  host  computer.  By  this 
means  remote  users  can  review  or  update  the 
JDS  data  base. 

—  Transfer  of  portions  of  the  JDS  data  base 
to  remote  sites  is  possible  using  WIN.  Then 
users  at  remote  sites  can  run  command  unique 
applications  programs  using  their  copies  of 
the  JDS  data  base.  These  copies  of  the  data 
base  will  not  reflect  updates  to  the  data  base 
at  JDA  unless  a  later  transfer  is  initiated. 

Direct  access  to  the  JDA  data  base  is 
possitle  throught  the  JDS  Remote  Users  Package 
(HUP)  which  permits  the  user  to  update  a  local 
copy  of  the  JDS  data  tase  while  simultaneously 
updating  the  JES  data  base  resident  on  the  JDA 
computer.  This  permits  commands  to  have 
access  to  the  most  up-to-date  version  of  the 
JDS  data  base  en  a  real  time  basis. 

The  RUP  is  considered  to  be  the  prefered  method  for 
timely  transfer  of  information  between  JDA  and  the  remote 
sites  since  it  not  only  provides  the  remote  user  the  capa- 
bility for  timely  submission  of  updates  and  changes  tut  also 
permits  the  remote  user  to  recieve  changes  simultaneously 
as  the  JDS  data  base  is  updated  by  other  members  of  the 
deployment  community.  In  addition  the  RUP  permits  the 
remote  user  to  run  command  unique  applications  programs 
using  the  local  copy  of  the  data  base.  "As  part  of  the  RUP, 
the  JDA  has  developed  communication  support  software  called 
the  JDS  Interface  Processor  which  uses  existing  WIN  to 
support  transaction  updates  between  two  WIN  sites  in  near 
real  time."  [  Ref.  7:   p.  70]. 
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The  JDS  also  interfaces  with   MAC  and  MTMC  using  WIN 
to  transfer  informaticn  to  and  from 

the   Integrated   Military    Airlift   Planning   System 
(IMAPS)  at  Military  Airlift  Command 

-  the  Motility  Analysis  a  Ed  Planning  System  (MAPS  II)  at 
Military  Traffic  Management  Command. 
These  automated   interfaces  facilitate  the  timely   exchange  of 
movement  requirements   and  scheduling  information   between  JDA 
and  the  TOAs. 

E.   SPECIFIC  PBOBLEMS 

Several  examples  cf  the  kinds  of  problems  which  cccur  in 
processing  in  a  distributed  environment  can  be  found  in 
examining  the  JDS  as  part  of  the  WWMCCS  ADP  support  for  CPE. 

a.   Interface  Between  JOPS  and  JDS 

The  JDS  is  the  ADP  tool  used  to  manage  informa- 
tion in  support  of  deployment  and  OPLAN  execution.  In  order 
to  properly  support  its  mission  the  JDS  must  interface  with 
JOPS  which  is  used  tc  develop  oplans.  The  current  interface 
is,  "time-consuming  and  relies  heavily  on  manual  reviews  and 
manipulation  of  'data1,"  [Ref.  8:  p.  8].  The  JOPS  handles 
notional  data,  dealing  with  types  of  units  rather  than 
specific  named  units.  JDS,  however,  has  in  its  data  bases 
specific  named  units  which  will  be  used  in  specific  plans. 
In  order  to  obtain  the  proper  information  for  the  JDS  data 
base,  manual  reviews  cf  the  notional  JOPS  data  are  conducted 
and  after  specific  actual  units  are  named  in  support  of 
requirements,  the  JDS  data  base  is  prepared.  In  addition, 
each  cf  the  TOAs  requires  support  from  command  unique  soft- 
ware to  convert  the  notional  movement  tables  from  JCPS  into 
schedules  which  use  actual  named  assets.  These  schedules 
are  then  used  to  provide  input  for  the  JDS  data  base. 
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The  interfaces  among  these  systems  are  primarily 
manual  at  the  present  time.  In  addition,  although  the  PIN 
is  used  to  transfer  data  between  participating  commands, 
each  ccumand  running  JO?s  uses  its  own  copy  of  the  1PFDD 
during  processing  as  well  as  its  own  copy  of  the  JOFS  soft- 
ware. This  results  in  considerable  duplication  of  files  and 
a  resulting  requirement  for  extensive  coordination  tc  ensure 
each  site  is  using  copies  of  the  same  TPFDD  data  base  in 
order   to   prevent   decrepancies. 

t.      NOPLAN    Support 

"There  are  no  adequate  procedures  to  rapidly 
establish  a  deployment  data  base  in  a  NOPLAN  situation," 
[Ref.  8:  p.  11]-  Since  in  the  current  JDS  the  only  way  to 
review  data  is  in  connection  with  one  specific  OPLAN  at  a 
time,  it  is  difficult  to  efficiently  use  data  already  in  the 
data    base    in      support   of   a    NOPLAN   situation.  There    is    not 

even  automated  assistance  to  determine  which  units  are 
tasked  tc  support  more  than  one  OPLAN.  This  is  a  deficiency 
in  the  current  system  since  there  is  a  validated  requirement 
that,  "The  JCS  will  review  the  supported  commander's  esti- 
mate and  approve  or  ncdify  the  recommended  course  of  action 
after  determining  the  effect  on  other  operation  plans  and 
global  capabilities,"  [Ref.  9:  p.  12].  There  is  currently 
no  timely,  efficient  way  for  commanders  to  share  NCPIAN 
information  when  developing  potential  courses  of  action 
without  actually  sending  copies  of  data  bases  or  lengthy 
messages    between  commands. 

c.      Data   3ase   Inconsistencies 

The  primary  method  for  transfer  of  data  among 
commands  using  the  JES  is  the  WIN.  Recent  tests  conducted 
during  a  major  exercise  have  shown  in  a  fairly  small  sample 
cf      JDS        data      base        records      that        there      are         numerous 
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inconsistencies  among  copies- of  the  data  base  at  various 
sites  (Jcint  Deployment  Agency,  European  Command,  Military 
Airlift    Ccmmand)  : 


"The  technique  we  used  to  determine  the  synchronization 
of  JDS  data  bases  was  to  select  a  sample  of  carrier 
records  and  determine  if  the  information  was  the  same  in 
each  of  the  three  data  bases.  .  -This  oplan  has  thou- 
sands of  carriers,  so  we  limited  our  sample  tc  these 
carriers  we  knew  had  been  updated--those  with  Deviation 
and  /or   Diversion   reports.  We   retrieved   carrier    mani- 

fest data  on  forty-five  records  stored  at  each  of  the 
three  locations  ...  In  summary,  this  very  small  sample 
of  carrier  records  having  been  modified  By  deviation/ 
diversion  reports,  had  a  high  percentage  or  differences 
between   RDP   and   JDS  data    bases."      [Ref.    10] 


The      data      shown      furnishes    examples      of      the      discrepancies 
found:      [Ref.    10] 

CARRIER    A03895  SCH   ARR 

EUCCfl  255426ZFEE    AT    BRUSSELS 

JDA  2500000FEE    AT    BRUSSELS 

Discrepancy:       a   difference   in   scheduled   arrival   time 

CARRIER    A04526  SCH   DEP 

SUCCM  CITY   OF    COLORADO    SPRINGS     (TDHV) 

JDA  PETERSON    FIELD  (TDHV) 

Discrepancy:         a    difference    in    the      name   associated    with  a 
specific   location    cede 

CARRIER    A04021v  SCH   ARR 

EUCCM  251626ZFEB 

JDA  2500000FEE 

Discrepancy:       a   difference   in   the   scheduled  arrival   time 

CARRIER    A04182               SCH    ARR                    CARRIER    DEVIATION 
EUCCM  261651 ZFEE  
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JDA  2600000EEE  DELAYED    2    HOURS    CUE    TO 

DEMONSTRATION    AT    AFCD 

Discrepancy:  a  difference  in  the  scheduled  arrival  tine 
and  a  note  concerning  carrier  deviation  which  only  shows 
at    cne   site 

The  need  for  complete,  accurate,  timely  informa- 
tion is  often  taken  for  granted.  In  the  CPE  environment 
this  requirement  is  even  more  challenging  since  all  partici- 
pating commands  need  to  be  working  with  identically  updated 
data  rases  if  they  are  to  make  valid  assumptions  for  plan- 
ning   and  executing    oplans. 

d.      Data   Base   Management 

"There  is  also  a  requirement  to  develop  a  system  to  restrict 
access  to  data  and  restrict  the  capability  to  change  data 
elements  within  JDS,"  [Hef.  11:  p.  2-10].  Safeguards  to 
prevent  unathorized  changes  to  data  elements  in  the  JDS  are 
insufficient.  An  authorized  JDS  user  with  modify  permis- 
sions nay  make  unauthorized  modifications  in  the  data  base 
since  individual  types  of  changes  or  types  of  data  elements 
are    insufficiently    safeguarded. 

A  change  or  update  to  the  JDS  data  base  using 
one  update  module  nay  or  may  not  update  relevent  corre- 
sponding data  elements.  For  example,  if  a  carrier  is 
reported  as  sunk  using  one  update  module  a  query  module  to 
display  ships  arriving  on  a  given  date  may  still  display  the 
ship    as    scheduled   to    arrive. 

"A  major  problem  facing  the  deployment  community 
is  the  lack  of  standardization  of  data  elements  between  the 
JOPS,  JDS,  UNITREP,  and  OPREP.  Because  of  the  need  to  acco- 
modate the  interface  with  these  systems,  JDA  has  been  forced 
to        pick      and        choose     between        various      data         elements, 
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definitions  and  formats,"  [Eef-  11:   p-  3-8],   The  following 

are   seme  of  the   problems  resulting   from   the  attempt   to 
interlace  these  systems: 

-  data  elements  which  actually  have  the  same  meaning 
have  different  names  (e.g.  different  versions  of  an 
airfield  name  associated  with  the  same  location  code) 

-  data  elements  which  have  the  same  meaning  may  have 
different  units  or  be  calculated  using  different  algor- 
ithms (e.g.  weight  reflected  in  long  tons  on  one  system 
and  short  tons  on  another) 

-  data  elements  which  have  different  meanings  have  the 
same  names  (e. g.  arrival  date  on  one  system  may  he  the 
time  a  unit  will  arrive  in  theatre,  on  another  system  it 
may  be  the  time  a  unit  will  arrive  at  port  of  debarka- 
tion) 

As  the  data  base  structure  or  the  basic  software 
of  the  JES  changes,  the  command  unique  queries  written  to 
run  against  the  JDS  data  base  must  also  be  changed. 

C.   BEQOIEEMENTS 

In   July  1983   the  Joint   Chiefs  of   Staff  approved   the 
Joint   Operation   Planning   and   Execution   System   (JCPES) 
Eequired  Operational   Capability.    The   initial  operational 
concept, 

"Addressed  procedures  supported  by  state-of-the-art  AD? 
capabilities    which    would    result     in    producing 


.gainst  deployment  and  sustainment  capL 
ities,  within  days.  These  criteria,  once  achieved, 
represent  a-  revolutionary  improvement  to  present  plan- 
ning system  capabilities."   [Ref.  9]. 
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JCPES  is  envisioned  as,  "The  foundation  for  our  conven- 
tional command  and  ccntrol  system,"  and  will  accomplish  its 
functions,  "through  the  interoperation  of  a  central  core  of 
joint  applications  and  various  C2  and  functional  systems  .  . 
.  JOPES  irust  support  the  planning  and  execution  of  multi- 
theater  scenarios  involving  total  commitment  of  U.S.  and 
Allied   forces,"    [Ref.    12]. 

JOPES  will  effectively  replace  the  JOPS  and  JDS  which 
today   support   CPE.  JOPS    and   JDS    are      two   separate    systems 

which    do   not  have   an    automated   interface.         JCPS    is    used   for 
planning      and     JDS      for     execution.  .In      JOPES,         software 

supporting      these    functions      would      not      require    the      iranual 
interfaces      required    today.  In  addition,        JOPES    will      be 

required      to  share      data     with      command   unique     applications 
which   support  CPE. 


"JOPES  consists  of  the  policy,  procedures.  software, 
hardware,  personnel  training,  and  connectivity  necessary 
to  facilitate  planning  directing  coordinating,  moni- 
toring and  controlling  military  operations."  [Ref.  9: 
P-    2] 


For  JOPES  tc  work  effectively  the  WWMCCS  community  will  have 
to  develop  and  support  a  distributed  data  base  concept  which 
will  pernit  interfacing  command  unique  software  and  system 
standard  software.  In  a  distributed  data  base,  portions  of 
the    data   are      stored    en    different   computers.  The    physical 

location  of  the  data  ideally  does  not  affect  processing  and 
is  usually  not  even  apparent  to  the  user.  This  would  elimi- 
nate the  need  for  synchronizing  multiple  copies  of  data 
bases  (except  these  required  for  redundancy).  Such  an  envi- 
ronment would  also  eliminate  the  manual  manipulation  of  data 
currently  required  in  interfacing  the  existing  systems  which 
support   CPE. 
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IV.    RECOMMENDATIONS 

A.       CHANGING   ENVIRONMENT 

The  current  state  of  the  art  in  automatic  data 
processing  offers  many  management  and  technical  opportuni- 
ties to  facilitate  the  transition  from  the  WWMCCS  Standard 
ADP  of  today  to  the  kind  of  system  required  to  support  the 
evolving  needs  of  the  CPE  environment.  The  requirement  to 
share  data  among  commands  in  support  of  CPE  requires  addi- 
tional techniques  and  facilities  not  required  by  a  single 
site  operating  in  isolation.  The  Open  System  Interface 
reference  model  proposed  by  the  International  Standards 
Organization  provides  a  means  to  describe  and  document  the 
interfaces  required  in  a  computer  networking  environment. 
The  capatilities  provided  by  local  area  networking  offer  the 
facility  to  link  internal  command  resources  together  in 
support      of        command      unique      requirements.  The      WWMCCS 

Information  System  is  the  onging  program  to  modernize  WWMCCS 
ADP  utilizing  modern  technology  to  meet  evolving  require- 
ments. 

1  •      Open  Sy_s te m    Interface   Bef erence   Standard 

The  International  Standards  Organization  (ISO) 
proposed  the  Open  System  Interface  (OSI)  Reference  Model  to 
serve  as  a  standard  set  of  network  interfaces  and  protocols. 
The  use  of  the  OSI  Beference  Model  would  be  a  step  toward 
international  standardization  of  the  various  protocols  for 
distributed     processing        networks.  Compatibility        among 

network  nodes  would  te  assured  by  compliance  with  standards 
even  when  software  and  hardware  at  various  sites  are 
supplied   by   different   vendors. 
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The  OSI  standard  is  based  on  a  seven  layer  concept. 
Each  layer  provides  a  portion  of  the  services  required  to 
interface  nodes    in    the   network.  By   breaking  the    interface 

problem  into  seven  layers,  the  implementation  of  different 
portions  of  the  interface  can  be  developed,  tested,  fielded, 
and  modified  independently.  The  layered  approach  helps  to 
isolate  the  functicnal  requirement  from  the  engineering 
implementation.  As  more  efficient  technology  becomes  avail- 
able the  implementation  cf  a  specific  portion  of  the 
interface  can  be  changed  without  undue  influence  on  the 
users1    interaction    with  the    overall   information   network. 

The  bottom  three  layers  of  the  OSI  model  are  host  to 
imp  protocols  and  the  top  four  layers  are  host  to  host 
protocols.  Only  the  top  two  layers  deal  with  interfacing 
user    applications  and  data. 

LAYEB  1:  The  Physical  Layer  supports  the  actual  communi- 
cation connection  between  hosts  and  the  transmission  of 
raw    data    ever    the   established   channel. 

LAYEB  2:  The  Data  Link  Layer  ensures  data  received  is 
error  free  and  the  appropriate  acknowledgements  are 
sent. 

LAYEB  2:  The  Network  Layer,  sometimes  called  the  commu- 
nication subnet  lajer,  is  responsible  for  point  to  point 
routing  of  data   between   its   origin   and   destination. 

LAYEB  4:  The  Transport  layer,  also  called  the  Host-Host 
layer,  is  concerned  with  dividing  the  data  into  packers 
for   transmission. 

LAYEB  5:  The  Session  Layer  provides  the  capability  for 
users  cf  different  machines  to  establish  a  connection 
between   processes   on  the    machines. 
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LAYEB  6:  The  Presentation  Layer  manages  the  exchange  of 
data  b€tween  applications  anywhere  on  the  network.  It 
ensures  tie  data  is  in  appropriate  format  for  the  appli- 
cation  to   which   it    is   being   sent. 

LAYEB  7:  The  Application  Layer  provides  the  interfaces 
between  user  and  application  and  the  user  and  the 
system. 
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Figure    4.1        Network  Based  on  ISO   OSI   Reference  Model. 
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Figure  4.1  [Bef.  13:  p.  16],  illustrates  a  network 
based  on  the  ISO  OSI  Reference  Model.  The  dotted  lines 
represent  virtual  connectivity  between  similar  layers  on 
different  hosts  while  the  solid  lines  represent  physical 
connectivity.  The  ISO  OSI  provides  a  useful  way  of 
describing  protocols  which  perform  required  network  func- 
tions while  leaving  the  engineering  of  the  implementation  up 
to  the  netwcrk  designers. 

2-   local  Area  Networks  (LAN) 

local  area  networks  (LAN)  are  networks  which  provide 
high  speed  communications  among  information  processing 
equipment  in  a  limited  geographic  area.  Local  area  networks 
have  evolved  from  previously  existing  methods  of  networking 
and  communicating.  They  provide  the  capability  to  interface 
many  kinds  cf  devices  and  to  exchange  data  with  other  LANs 
or  long  haul  networks.  In  general,  LANs  offer  high  data 
transmission  speed  at  lowered  costs  wnile  sacrificing  long 
distance  data  transnission  capability.  LANs  are  a  key 
element  in  the  strategy  for  the  WWMCCS  Information  System. 
Attributes  of  LANs  which  are  being  evaluated  for  support  of 
WIS  include: 

flexible  topology 

security 

expandability 

flexibility   in  selecting    transmission   media 

reliability. 

3.      jJWMCCS    Information    System    (WIS) 


"The  WWMCCS-  Information  System  (WIS)  encompasses  the 
information  collection,  processing,  and  display  system 
that  includes  WWMCCS  ADP  and  related  software  systems, 
procedures     and      supporting        telecommunications.  The 

modernization  focus  is  on  the  backbone  of  standard 
WWMCCS  ADP  which  supports  command  systems  .  .  .  The  JPM 
(Joint  Program  Manager)  focus  will  be  on  software  and 
aata   management   techniques."      [ Ref .    14:      p.    ES-1] 
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The  WIS  is  explained  triefly  in  order  to  shed  some  light  on 
the  current  effort  to  improve  WWMCCS  AD?  which  will  affect 
the  ADP  environment  in  which  CFS  users  operate.  The  support 
provided  by  WIS  will  be  implemented  incrementally . thereby 
providing  evolutionary  modernization-  This  will  help  mini- 
mize the  overall  impact  on  command  and  control  users  while 
permittirg    advances    in   computer    technology    to   be    utilized. 


"The  KIS  JPM  task  is  to  modernize  and  enhance  the 
command  control  software,  acquire  state-of-the-art  hard- 
ware and  add  capabilities  to  the  command  control 
Erocess.  These      capabilities    include      automating      the 

andling  of  operational  messages,  distributing  data  and 
enhancing  the  capability  of  command  control  personnel  to 
interact    with    their  information."      [Ref.     15:      p.    17] 


Figure  4.2  [fief.  16],  illustrates  the  capabilities 
to  be  provided  by  WIS.  In  implementing  WIS  one  goal  is  to 
maintain  the  separation  of  the  the  engineering  inplementa- 
tion  fron.the  desired  capabilities.  In  other  words,  various 
commands  may  use  different  hardware  and  software  to  support 
their  sites.  In  addition,  LANs  will  provide  tailored 
support  for  internal  requirements  of  commands  while  still 
permitting    and    interface  with    the   long   haul   network. 

4 .      Summary 

The  recurring  emphasis  in  state-of-tne-art  ADP  tech- 
nology is  interfaces  which  permit  the  separation  of 
engineering  and  function.  This  should  permit  the  users  to 
select  tie  implementation  best  suited  to  their  needs  and 
still  interact  with  other  users  supported  by  different 
implementations.  This     conceptually      permits      systems      to 

continue   to   grow      and  evolve,      making   use      of   new    technology 
without    disrupting    the   supported    functions. 
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•  OUTGOING  MESSAGES 

•  QUERY/ RESPONSE 

•  TELECONFERENCE 
t  DISPLAYS 
0  OATA  BASE  SUMMARIES 


•  JRS  MESSAGES 
t  OTHER  MESSAGES 
•  QUERY/RESPONSE 
•  TELECONFERENCE 
•  DISPLAYS 
a  DATA  BASE  UPDATES 
FILE  TRANSFERS 


EXTFRNAL  INTERFACES 


LOCAL  USER  WORK  STATIONS 

•  COWANO  CENTER  PERSONNEL 

•  CRISIS  ACTION  TEAMS 

•  OPERATIONS  SUPPORT  PERSONNEL 


Figure  4.2   User  Capabilities  Supported  by  IIS 
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E.   STANEABEIZATION  -  A  NEW  APPROACH 

Ihe  growing  requirement  for  automated  interfaces  between 
the  programs  and  data  bases  used  by  different  commands  to 
support  CPE  cannot  be  supported  using  the  current  W EM CCS 
Standard  Software.  If  commands  want  to  interface  software 
today,  the  interfaces  must  be  designed  individually  and 
uniquely  tailored  to  the  two  ends  of  the  interface.  Figure 
4.3  illustrates  the  interfaces  which  would  be  required  to 
link  the  software  of  four  members  of  the  joint  deployment 
community  today.  Each  line  represents  a  specific  interface 
developed  between  applications  at  two  commands.  In  this 
example  six  programs  are  required  to  interface  each  of  the 
four  ccmirands  to  each  of  the  other  three. 


Figure  4.3    Interfacing  under  WWMCCS  Today. 

It  is  clear  that  in  addition  to  necessitating  many  man- 
years  of  software  development,  an  interface  would  require 
updating  each  tine  an  application  on  one  end  was  modified. 
The  requirement  still  exists,  however,  to  share  data  among 
commands.   In  JOPES, 


"Once  an  originating  agency  updates  its  data  base,  the 
distributed  data  rase  concept  will  permit  automatic 
updating,  in  summary  format,  of  all  interrelated  data 
bases  .  .  .  JOPES  will  not  burden  lower  level  staffs 
with  extensive  reporting  requirements  but  will  interface 
with  command  and  agency-unique  systems  as  necessary  and 
within  owner  specified  limits  to  rapidly  obtain  informa- 
tion."  [fief.  9] 
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JDA  has  Bade  progress  with  near  real-time  updating  of  data 
bases  located  at  different  commands  but  the  JDS  requires  all 
participating  commands  to  be  using  exactly  the  same  JDS 
software,  operating  on  the  same  WWMCCS  Standard  Hardware. 
This  approach  does  net  permit  the  interfacing  of  cemmand 
unique   applications    and   data   bases   among   commands. 

In  order  to  obtain  the  benefits  of  timeliness  and  accu- 
racy in  interfaces,  an  ADF  solution  is  preferable  tc  the 
current  manual  interfaces.  If  the  WWMCCS  community  would 
define  a  cere  set  of  data  which  is  required  for  CPE  and 
standardize  the  description  cf  this  data,  each  command 
seeking  to  interface  with  another  command  would  only  have  to 
develop  an  interface  between  tbe  standard  data  set  and  their 
command  unique  software.  Figure  4.4  illustrates  the  Joint 
Deployment    Community    interfacing   in   this    manner. 


Figure  4.4        Interfacing    through   a   Standard  Data   Set. 

The  total  number  of  interfaces  would  be  reduced  signifi- 
cantly and  each  cemmand  would  only  have  to  plan  cne 
interface  with  the  standard  data  set  in  order  to  interface 
an  application  with  all  other  participating  commands.  In 
this  example  the  total  number  cf  interfaces  was  reduced  from 
six  to  four  by  interfacing  through  a  standard  data  set. 
More  important,  each  node  new  only  requires  one  interface 
vice    the      three    previously    required.  The  use   of      a   ccramon 
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interface  permits  many  widely  separated  data  bases  to  func- 
tion virtually  as  a  distributed  data  base.  This  will  help 
meet  the  identified  requirement  for  a  distributed  data  base 
approach  tc  support  JOPES.  It  is  not  a  distributed  data 
base  in  the  routine  sense  but  rather  an  interface  which 
permits  the  exchange  of  data  among  separate  data  bases. 
This    concept  is    further   developed   in   a   later   section. 

1  •      Electronic    Data   Interchange     (2D I) 

a.      Background 

"The  U.S.  Electronic  Data  Interchange  (SBI) 
Standards  are  designed  to  facilitate  the  electronic  inter- 
change of  data  in  a  standard  manner  between  independently 
organized,  owned  and/or  operated  computer  and  communications 
systems,"  [Eef.  17:  p.  9].  The  EDI  standards  were  devel- 
oped in  an  extensive  joint  government-industry  effort  to 
meet  a  recognized  need  in  the  transportation  industry  for 
timely,  reliable  transmission  of  data  among  organizations. 
The    organizations   utilizing    the    EDI    standards   include: 


Motor   Carriers 

Ocean    Carriers 

Air   Carriers 

Railroads 

Brokers 

Shippers 

Consignees 

Freignt   Forwarders 

Freight   Ccnsolidatcrs 

Banks 

Agents 

U.S.  Customs  Service 

U.S.  Department  of  Agriculture 

U.S.  General  Services  Administration 

U.S.  Department  of  Defense. 
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t.      Structure   of   EDI 

The  major  unit  of  information  in  EDI  is  the 
transaction  set.  Transaction  sets  support  the  major  func- 
tions performed  by  the  communicating  organizations. 
Information   units  in    the   EDI  include: 


"Data  Element:  The  smallest  information  unit  in  the  EDI 
information  structure  is  the  data  element.  A  data 
element  may  be  a  single  character  code,  a  series  of 
characters  constituting  a  literal  description,  or  a 
numerical    quantity. 

Data  Segment:  A  data  segment  is  composed  of  a  function 
identifier  and  one  or  more  functionally  related  data 
elements  positioned  serially  in  a  standard  manner  .  .  .A 
segment  is  roughly  equivalent  to  a  line  of  information 
on    a   hill   of    lading   or   freight    bill. 

Transaction  Set:  A  transaction  set  is  a  group  of  data 
segments,  in  a  predfined  sequence,  needed  to  provide  all 
of  the  data  required  to  define  a  complete  transaction 
such  a  s  shipment  information  or  invoice  .  The  trans- 
action set  in  EDI  equates  to  a  document  in  a  paperwork 
system,    such    as   a    hill  of    lading   or    invoice. 

Functional  Group  cf  Transaction  Sets:  A  functional 
group  identifies  these  transaction  sets  of  the  same  type 
"(having  the  same  indentifier  and  subject  title)." 
[Ref.    18] 


Figure  4.5  [Eef.  19],  shows  how  the  information  units  are 
put  together  to  build  a  complete  transaction  set.  The  first 
data  segment  shown  in  the  second  column  of  the  example  is 
composed  cf  the  first  four  data  elements  in  the  first 
column.  This  same  data  segment  becomes  the  first  part  of 
the  transaction  set  in  column  three.  It  should  be  noted 
that  a  data  element  (e.g.  A)  can  be  used  in  more  than  cne 
data    segment. 
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Figure  4.6  [ Ref .  19],  shows  how  a  communications 
session  with  a  user  inputting  data  into  the  network  can 
include  core  than  one  transaction  set.  This  figure  fellows 
the  building  block  approach  by  showing  that  related  trans- 
action sets  (e.g.  purchase  orders)  can  be  regarded  as  a 
functional  group  and  several  related  or  unrelated  functional 
groups    can    be   sent    in   the   same    transmission. 

c.      EDI    Operations 

The  EDI  concept  operates  through  the  use  of  five 
tables. 


"The   same   five  tables   are    used   for   generation    of    data   to 

be    transmitted  and      for  the   interpretation   of      data    that 

is    received.  The     set  of   tables   defines      the    structure 

and   attributes  of    the  EDI   transaction      sets,      segments, 

data    elements,  and    codes.         The   EDI   operational    software 
programs    control      pointers   to   these      tables   and      use    the 

information  at  the  pointer      locations,      in     combination 

with   data   from  the    user's      data   base,      to   assure    program 

generation  and  interpretation   of    data."      [Ref.     19] 


These  tables  are  used  to  process  incoming  and  outgoing  data. 
Figure  4.7  [Ref.  19],  explains  generally  how  the  tables  are 
used.  Figure    4.8      [Ref.     19],        presents      a   more      detailed 

example  of  the  data  structure,  with  sample  entries  for  each 
table  described  in  figure  4.7  Table  1  has  a  list  of  all 
transaction  sets  with  identifying  numbers.  Table  2  lists 
the  data  segments  in  each  transaction  set.  Table  3  is  a 
directiory  of  all  data  segments  with  identifying  numbers. 
Table  4  lists  the  data  elements  in  each  data  segment.  Table 
5  is  the  data  dictionary  and  is  broken  down  by  data 
elements.  Detailed  examples  of  each  table  are  given  in  a 
later   section.. 
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Communications  Protocol   "~ ~ " ■"•"■■"■■ ~~- ~ ~-~~ ~~ 
Transmission  Control  rieaoer  Segment  (BG) 
Functional  Control  Header  Segment  (GS) 


Transaction  Set  Control  Header  Segment  (ST  ) 
(Beginning  Segment) 


Detail  Data  Segments 
le.g.  Purcnase  Order) 


Transaction  Set  Control  Trailer  Segment  (SE) 
(Ending  Segment) 

Transaction  Set  Control  Header  Segment  (ST  ) 
(Beginning  Segment) 


Detail  Data  Segments 
(e.g.  Purcnase  Oroer) 


Transaction  Set  Control  Trailer  Segment  (SE! 
(Ending  Segment) 


Functional  Control  Trailer  Segment  (GE)> 
Functional  Control  Heaaer  Segment  (&S) 


Transaction  Set  Control  Header  Segment  (ST  ) 
(Beginning  Segment) 


Detail  Data  Segments 
(e.g.  Receiving  Advice) 


Transaction  Set  Control  Trailer  Segment  (3E)- 
<Ericing  Segment) 


Functional  Control  Trailer  Segment  (Gt) 
Transmission  Control  Trailer  Segment  (EG) 
Communications  Protocol  — ^— — . — ^^— — 
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Figure  4.6        A  CoMunications  Session 
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Table 

1  is  used 

to  locate  items  in  Table 

2. 

Table 

2  gives  the  order  of  segments  in  a 

trans. 

action  set 

for  each  application. 

Table 

3  is  used 

to  locate  items  in  Table 

4. 

Table 

4  gives  the  order  of  data  elements 

in  each  segment 

» 

Table 

4  example 

(simplified) : 

Segment  I.D. 

• 

Data  Element    Location 

EX 

• 
• 

(Example) 

D             11 

EX 

A              1 

EX 

E             13 

EX 

• 
• 
• 

C              9 

Table 

5  specifies  data  element  attributes. 

Table 

5  example 

(simplified)  : 

Data  Element    Maximum  Lenath 

A 

4 

B 

4 

C 

2 

D 

2 

E 

12 

F 

• 
• 
• 

8 

Figure   4.7       Use   of   Tables   in    EDI. 
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d.   Advantages  of  EDI 

The  emphasis  in  the  EDI  concept  is  on  communica- 
tions (exchange  of  information)  between  computers.  By 
communicating  through  the  use  of  standard  transaction  sets, 
EDI  permits  users  to  interface  efficiently  while  preserving 
their  autonomy.  Each  user  could  conceivably  be  using 
different  kinds  of  hardware,  software,  and  data  base  manage- 
ment systems  and  still  be  able  to  communicate.  An  added 
benefit  cf  the  EDI  approach  is  that  data  elements  can  be 
added  or  deleted  without  requiring  software  logic  changes. 
Also,  changes  in  a  user's  applications  will  not  affect  the 
interface  with  other  users  as  long  as  the  translation  tc  the 
EDI  standard  is  updated  within  the  command. 

The  EDI  concept  could  be  used  within  the  WWMCCS 
community  tc  ease  the  transition  to  the  distributed  data 
base  environment  which  will  be  required  to  support  CPE.  To 
implement  this  approach,  members  of  the  WWMCCS  community 
would  have  to  define  the  applications  and  the  data  which  are 
required  to  support  CPE.  Standard  methods  for  data  control 
would  be  required.  Once  the  standards  were  developed  and 
documented  it  would  be  the  responsibility  of  each  command  to 
make  the  translation  between  their  applications  and  the 
standard.  Cnce  all  the  involved  commands  are  able  tc  trans- 
late between  their  applications  and  the  standard,  they  could 
also  ccmmunicate  directly  with  ether  participating  commands. 

2  •   Application  tc  Specific  Problems 

The  desirability  of  implementing  the  EDI  concept 
within  the  WWMCCS  cemmunity  can  be  evaluated  by  examining 
how  it  would  help  resolve  the  some  of  the  problems  which 
have  been  identified  in  WWMCCS  ADP  support  of  CPE. 
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a.   Data  Base  Management 

In  order  to  ensure  the  accuracy  of  data  the 
capatility  to  modify  cr  delete  data  must  be  controlled.  Ihe 
current  system  dees  net  protect  against  unauthorized  changes 
made  by  a  user  who  is  authorized  access  to  some  but  not 
neccessarily  all  data.  The  EDI  concept  would  contribute  to 
security  because  the  data  elements  would  be  distributed 
among  the  commands  with  ultimate  control  and  modify  permis- 
sions held  by  the  command  "owning"  the  data  and  responsible 
for  its  accuracy.  Another  command  could  reguest,  data  but 
the  system  would  check  to  validate  the  identity  of  the 
sender,  in  accordance  with  pre-arranged  agreements, 


"The  communications  protocol  provides  a  means  for  posi- 
tive identification  of  the  sender  by  the  receiver,  and 
conversely  .  •  .  Processing  of  transmissions  which  do 
not  pass  the  comnmunication  header  validation  tests  is 
aborted  after  an  error  reply  is  sent  to  the  sender  and 
the  conditions  have  been  logged  for  subsequent  study  or 
analysis."  [Ref.  17] 


Ey  distributing  the  data  and  controlling  communications 
access  tc  specific  data,  the  EDI  concept  provides  more  secu- 
tity  than  the  current  system. 

In  the  current  system  a  change  or  update  to  the 
JDS  data  base  using  one  update  application  may  or  may  not 
update  relevent  corresponding  data  elements.  Using  the  EDI 
approach,  many  applications  could  rely  on  a  single  ccpy  of  a 
data  element  so  the  opportunity  for  discrepancies  would  be 
minimized.  Today  different  applications  use  different  files 
and  it  is  difficult  tc  effectively  update  all  instances  of  a 
data  element.  In  addition,  through  use  of  the  transaction 
sets,  groups-  of  related  data  elements  could  be  updated 
together. 
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The  current  lack  of  standardization  of  data 
elements  among  standard  and  command  unique  systems  can  be 
significantly  reduced  through  the  use  of  the  EDI  concept. 
Initially  an  effort  would  be  required  to  identify  data 
elements  which  must  he  shared  among  members  of  the  HHMCCS 
community.  The  definitions  of  these  data  elements  would  be 
specified  and  incorporated  into  a  standard.  Each  ccmmaand 
which  reeds  to  interface  with  another  in  the  community  would 
then  develop  the  necessary  software  to  translate  command 
data  elements  into  the  standard  format.  "The  interface 
computer  program  and  the  structure  of  each  type  of  trans- 
action set  are  part  of  the  EDI  standards.  EDI  does  not 
address  a  standard  which  extends  into  a  company's  internal 
system,"  [Eef.  17].  The  EDI  software  would  perform  the 
functions  which  would  facilitate  interfaces  among  partici- 
pating commands.  Cnce  data  to  be  interchanged  has  been 
defined  in  a  standard  definition,  individual  commands  can 
convert  data  elements  to  the  standard  through  individual 
software  routines.  This  would  resolve  the  following  kinds 
of  discrepancies: 

-  data  elements  which  actually  have  the  same  meaning 
have  different  names 

-  data  elements  which  have  the  same  meaning  may  have 
different  units  or  te  calculated  using  different  algcr- 
ithas 

-  data  elements  which  have  different  meanings  have  the 
same  names 

As  the  data  base  structure  or  the  basic  software 

of  the  JCS  changes,  the  command  unique  queries  which  rely  on 

the  JDS  data  base  often  must  be  rewritten.    The  EDI  concept 
is  designed, 


"To  respond  with  ease  to  frequent  requirements  for  modi- 
fication,   contraction,    and/or    expansion   of    the 
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individual  aoplications.  .  .  the  information  is 
structured  so  that  it  may  be  constructed  by  one  computer 
system  and  interpreted  and  processed  by  another,  New 
applications  and  information  units  may  be  specified 
without  impacting  work  previously  completed."  [Bef.  17: 
pp.    6-13] 


The  physical  implementation  (e.g.  the  programming  languages 
and  the  data  base  management  system)  of  any  standard  or 
unique  application  is  kept  isolated  from  the  standard  data 
definitions  so  modifications  to  implementation  methodology 
will    not   destabilize    the  system. 

t.      Data   Base  Inconsistencies 

The  problem  of  different  sites  having  different 
copies  of  the  data  tase  would  be  avoided  through  the  EDI 
concept  tecause  of  the  distribution  of  data.  Each  data 
element  would  reside  at  the  command  responsible  for  its 
accuracy  but  would  be  accessible  to  other  commands.  Even 
with  provision  for  redundancy  this  is  still  a  more  desirable 
arrangement  than  multiple  copies  of  data  bases  residing  on 
many  systems  at  many  locations.  In  this  way,  as  data  is 
updated  for  one  purpose  (e.g.  UNITHEP)  the  updated  data 
would  also  be  available  for  other  applications  such  as  JCPS 
or  JDS  without  requiring  separate  updates  for  each  applica- 
tion. 

c.      NOPLAN    Support 

The  use  of  the  EDI  concept  could  help  in  a 
NOPLAN  situation  by  eliminating  the  necessity  to  send  copies 
of  entire  data  bases  or  lengthy  messages  among  commands.  As 
each  ccmiand  successively  develops  a  portion  of  the  plan, 
data  can  be  ex-tracted  from  applicable  data  bases,  incorpo- 
rated into  transaction  sets  and  transmitted  to  ether 
involved     commands.  Because      the      construction        of      new 

instances   of  a    transaction    set   can   be   facilitated    by    the   EDI 
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tables  it  would  be  much  easier  for  commanders  to  evaluate 
various  alternatives  since  less  data  would  have  to  be  sent 
among  commands  to  generate  responses  to  "what  if  "  ques- 
tions. It  would  also  be  possible  to  include  as  part  of  the 
information  on  a  specific  unit  the  various  OPLANs  in  which 
the  unit  was  tasked-  This  could  be  done  by  developing  a 
data  segment  which  includes  as  data  elements  the  unit  desig- 
nation ard  the  plans  which  task  it.  In  this  way  potential 
problems   with   multi-tasking    could    be    identified    quickly. 

d.      The    Interface   Between   JCPS    and    JDS 

The  interface  between  JOPS  and  JDS,  and  other  standard  or 
command  unique  applications  could  be  significantly  siiipli- 
fied  through  the  EDI  CONCEPT.  Since  incompatibility  of  data 
elements  is  not  a  problem  when  the  common  interface  is  used, 
data  frcir  numerous  systems  could  be  tapped  in  response  to 
information   queries    input  using   any   one   of   the  systems. 

C.       IIPLEMENTATION 

Although  the  EDI  concept  requires  a  standard  set  of  data 
elements  in  order  to  operate,  there  is  no  centralized  stan- 
dard data  base.  EDI  facilitates  the  transfer  of  data  among 
various  data  bases  by  means  of  a  common  interface.  Laying 
the  groundwork  for  an  EDI  interface  is  in  some  ways, 
however,  siailar  to  data  base  design.  It  will  be  helpful  to 
examine  the  necessary  preparation  for  implementing  EDI  in 
data    rase    design  terns. 

A  data  base  is  a  model  of  an  organization  which  exists 
in  the  real  world.  Events  which  occur  in  the  real  world  are 
reported  to  the  data  base  system  as  transactions  which  in 
turn  cause  data  to  be  modified.  Design  considerations  for 
data  bases  as  models  are  listed  in  figure  4.9  [Ref.  20:  p. 
177]. 
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Database  as  a  model  of  an  enterprise 

Level  of  detail 

Cost  of  aggregation  and  generalization  is  unanswerable  question 
Need  to  aggregate  and  generalize  in  light  of  requirements  and 
financial  resources 

Dynamics  of  database  as  model 

Enterprise  changes,  model  must  change 

Events  occur,  are  represented  by  transactions 

Level  of  transaction  important  -  transactions  cannot  be  more 

aggregated  or  generalized  than  database  data 

User  views 

Different  perception  of  data  structure 
Different  perception  of  data  meaning 
Need  for  standardized  meaning 


Figure   1.9        Design   Considerations  for  Databases   as   Hodels. 

The    fact  that   in   CPE     users  represent    many   commands   with 
different   views    can    cause  a    design   problem, 


"Different  users  (and  desianers)  will  have  different 
meanings  and  interpretations  for  data  that  is  stored  in 
the  database.  Questions  that  appear  to  be  similar  may 
in    fact  be  different."     [ Ref .    20:      p.     177] 


Definition  of  a  set  of  data  elements  which  must  be 
available  in  an  EDI  interface  would  require  a  great  deal  of 
effort  with  high  level  support  in  the  joint  arena.  The 
standard  data  elements  will  be  the  building  blocks  from 
which   interfaces   will  be  constructed. 


•Data  tase  design  is  divided  into  two  phases:  logical 
design,  where  the  needs  of  people  are  specified,  and 
physical    design,    where  the   lcgical   design  is  mapped   into 
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the   constraints   cf   particular   program   and   hardware 
products,"  [Ref.  2C:   p.  177]. 


The  logical  data  bas€  design  is  done  by  the  users  who  need 
to  use  the  data.  The  physical  data  base  design  is  normally 
done  by  experts  skilled  in  evaluating  hardware  and  software 
capabilities  and  selecting  the  most  feasible  means  of  imple- 
menting the  logical  design,  This  division  of  effort  would 
apply  also  in  a  general  way  to  designing  a  standard  EDI 
interface,  although  it  is  not  a  data  aase  management  system 
per  se. 

1  •   logical  Data  Ease  D  esiqn 

a.   The  Output 

The  output  of  a  logical  data  base  design  is  a 
schema  which  defines  the  data  records  (in  EDI  terminology, 
the  data  segments)  which  are  to  be  maintained,  the  data 
elements  which  compose  them,  and  the  relationships  among 
these  data  segments  and  data  elements.  Data  segments  are 
descrited  by  listing  the  data  elements  which  they  contain 
and  constraints  which  limit  the  values  the  data  can  have. 
Transaction  sets,  in  turn,  are  described  by  listing  the  data 
segments  they  contain  and  applicable  constraints. 

h.   Input 

The  inputs  of  the  logical  data  base  design  are  the  system 
requirements  and  the  plan  which  describes  the  environment 
and  constraints,  which  will  affect  the  system. 

c.   Procedures 

"The  major  steps  in  the  logical  design  process: 

-  identify  data  to  te  stored 

-  consolidate  and  clarify  data  names 

-  develop  the  logical  schema 

-  define  processing 

-  review  design,"  [Eef.  20:   p.  181]. 
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In  the  process  of  identifying  the  data  tc  be 
stored,  the  data  dictionary  is  developed  and  data  elements 
are  identified  by  name  and  described.  Figure  4.10 
[Ref-  18",  is  an  example  of  a  portion  of  an  EDI  data 
dictionary.  To  see  how  the  data  dictionary  is  set  up, 
consider  data  element  "10"  in  the  left  column.  Data  element 
"10"  is  defined  as  a  six  digit  numeric  field  which  is 
entered  with  the  first  two  digits  representing  the  last  two 
digits  of  the  year,  the  middle  two  digits  representing  the 
month,  and  the  last  two  digits  representing  the  day  of  the 
month.  This  physical  description  of  the  data  element  is 
also  acccmpanied  by  a  verbal  definition  of  the  data  element. 

To  consolidate  and  clarify  data  names  it  is 
necessary  to  identify  synonyms  and  aliases.  Synonyms  are 
different  names  for  the  same  data  element.  Synonyms  should 
te  reduced  to  one  standard  name.  Aliases  are  alternate 
names  for  the  same  data  element  (synonyms)  which  are 
permitted  to  remain  in  the  system.  EDI  eliminates  the  need 
for  aliases  because,  although  different  users  may  have 
different  names  for  the  same  data  element,  they  can  provide 
for  "translation"  to  the  standard  by  means  of  the  software 
they  design  to  interface  their  unigue  system  to  the  EDI 
standard. 

The  development  of  the  logical  schema  consists 
of  defining  data  segments  and  their  relationships.  Figure 
4.11  and  figure  4.12  are  samples  of  two  EDI  tables  which 
list  data  segments  and  the  data  elements  from  which  they  are 
built.  [fief.  19].  In  Table  3  (figure  4.11)  the  data 
segment  titled  "beginning  segment  for  completed  payments"  is 
assigned  the  segment  ID  number  "B7".  This  data  segment  is 
composed  of  three  data  elements  (see  the  right  column) . 
These  data  elements  can  be  identified  using  Table  4  (figure 
4.12)  by  findicg  the  segment  ID  number  "B7"  in  the  first 
column.     The   second  column   lists   each   data   element 
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i 

DATA    ELEMENTS 

I 

I 
l 
i 

2 

ACCEPTED   SETS 

(SPEC:        TYPE-     N                   MIN'         1;     MAX'        3) 
NUMBER   OF    TRANSACTIONS    RECEIVED   WITHOUT    ERROR    IN   A 
FUNCTIONAL   GROUP    (NUMBER   MAY    BE   0) 

REFERENCE   DESIGNATOR! S i :       9502 

14 

CARRIAGE    VALUE 

(SPEC:       TYPE'    N                 MIN'       2:    MAX-       3) 

CARRIAGE    VALUE    EXPRESSED    IN   MHOLE    UNITS    OF    THE 

STANOARO   MONETARY   DENOMINATION    FOR    THE   CURRENCY                               i 

SPECIFIED    (IMPLIED   OECIMAL    POINT    IS    TO   THE    RIGHT 

OF   THE   EXPRESSED  VALUE.) 

REFERENCE  DESIGNATORIS):     M102 

3 

FREE -FORM  MESSAGE 

{SPEC:        TYPE'     AN                MIN'         1;     MAX' 
FREE-FORM   TEXT 

ALSO  SEE:      NOTE   REFERENCE  COOE    (343) 

60) 

15 

CARR   CERTIFICATED   REL.    DATE 

(SPEC:         TYPE-     N                    MIN-        6:     MAX-        6) 
DATE    IYYMMDO)    OF   CARRIER'S   CERTIFICATE   OF    RELEASE 
AS  REOUIRED  BY  CUSTOMS 

REFERENCE   DESIGNATOR! S) :      X303 

REFERENCE  DESIGNATOR! S ) :      IC201     NTE02 

3 

ARRIVAL    DATE 

(SPEC:       TYPE'    N                 MIN'       6:    MAX' 
DATE    IYYMMDO)    AS   REQUIRED  BY  CUSTOMS 
ALSO  SEE:      HA  DATE    —5  1 

6) 

16 

CHARGE    METHOD    OF    PAYMENT 

(SPEC:        TYPE-     A                    UIN'         1  ;     MAX'         1) 
CODE    DEFINING   METHOD   OF    PAYMENT: 

7 

REFERENCE  DESIGNATOR! S):      X302 

BANK    ACCOUNT   NUMBER 

(SPEC:       TYPE'    N                 MIN'       S:    MAX' 
ID   NUMBER    ASSIGNED   BY    SANK   TO   ITS   CLIENT 

REFERENCE  DESIGNATOR(S) :     C209 

17) 

COOE                        DEFINITION 
A        PREPAID   CASH 
B        PREPAID   CREDIT 
C       COLLECT  CASH 
0        COLLECT  CREDIT 
E       COLLECT 

REFERENCE  DESIGNATORIS):      (.111      .811 

a 

BANK   CLIENT   CODE 

(SPEC:        TYPE'     A                    MIN'         1 ;     MAX' 
IDENTIFICATION   OF    PAYEE   0*   PAYER: 

COOE                       DEFINITION 
E        PAYEE 
R        PAYER 

REFERENCE  OESIGNATORIS):     C201 

1) 

19 

CITY    NAME 

(SPEC:       TYPE-     AN              MIN'       2:    MAX'     19) 
FREE-FORM   TEXT    FOR   CITY    NAME 

REFERENCE  DESIGNATOR!  S) :      D401     3701      E401      E701 
F401      F701      F90*      H502 
L715      NA01      NAM05    RINO* 
S*02      S903      T20»      T210 
T&04      T&07      2T03      11*01 
U»01      V»05      Y10* 

9 

BANK    PLAN   NUMBER 

(SPEC:        TYPE'     N                    MIN'         1  ;     MAX'        6) 
NUMBER    ASSIGNED   SY   BANK   TO   PAYER'S    FREIGHT    PAYMENT 
ACCOUNT 

20 

CLIENT   BANK    NUMBER 

(SPEC:       TYPE'    N                 MIN'       3:    MAX-       9) 
FEDERAL   RESERVE   ROUTING  COOE    (SEE   APPENDIX  A-A4) 

REFERENCE  DESIGNATOR! S ) :      3*05     B703 

REFERENCE  DESIGNATORIS):      C20* 

10 

BANK   TRANSACTION   OATE 

(SPEC:       TYPE'    N                 MIN'       S:    MAX' 
DATE    (YYMMDDI    THE    BANK    RECORDED   THE    TRANSFER 
FUNDS 

REFERENCE  DESIGNATOR! S ) :      B703 

6) 
OF 

21 

C.O.D.    CURRENCY 

(SPEC;       TYPE-     A                 MIN'       2:    MAX-       2) 
STANOARO    ISO   COOE    FOR   THE   COUNTRY    IN    WHICH   THE 
C.O.D.    CURRENCY    IS   SPECIFIED   (SEE  APPENDIX  A-A5) 

REFERENCE  DESIGNATORIS):     C30S     C701 

11 

BILLING  CODE 

(SPEC:        TYPE'     A                    MIN'         1 ;     MAX'         1) 
TYPE    OF    BILLING   REQUIREMENT    FOR   MULTIPLE    EQUIPMENT 
SHIPMENT: 

22 

COMMODITY    COOE 

(SPEC:       TYPE-     AN              MIN'       2;    MAX-     10) 
ALPHA/NUMERIC    CODE    USED   TO   DESCRIBE    A   COMMODITY   OR 
GROUP    OF    COMMODITIES    FOR    RATING    ANO    BILLING   PURPOSES 
ALSO  SEE:      COMMOOITY  COOE   QUALIFIER    (23) 

COOE                       DEFINITION 

A        TEMPORARILY    ARTICULATED   LOAD 

M        MULTIPLE    SHIPMENT    SILLING 

0        MULTI-CAR    TRANSIT 

R        RULE    24    LEAD    AND   TRAILER    EQUIPMENT 

SINGLE   REYENUE   BILL 
S        SINGLE    SHIPMENT    BILLING 
T        TRANSIT    BILLING 
U        UNIT    TRAIN    BILLING 

REFERENCE  DESIGNATOR! S) :      B211 

■ 

23 

REFERENCE  DESIGNATORIS):      E*07     L503      1R03      1R0* 
1R05      1R0*      XR07      TD10* 
tTOl      H0111    M203 

COMMODITY    CODE    QUALIFIER 

(SPEC:       TYPE-    A                 MIN-        1 :    MAX'        1) 
QUALIFIER    FOR    THE   COMMOOITY   COOING    SYSTEM   USED   TO 
DEFINE    THE    ITEM   LADING   DESCRIPTION    I  SEE    APPENDIX   A- 
At    THRU   AL3,    A33I 

12 

BILLING   DATE 

(SPEC:        TYPE'     N                   MIN'        6:     MAX' 
OATE    (YYMMDD)    OF   THE  CARRIER'S    INVOICE 

REFERENCE  DESIGNATOR! S) :      B3M     COO*     R503 

6) 

COOE                          DEFINITION 

A        SCHEDULE    A.    TARIFF    SCHEDULES   OF    THE 

UNITED   STATES   ANNOTATED 
3        U.S.    FOREIGN    TRAOE    SCHEDULE    B.    STATISTICAL 
CLASSIFICATION   OF    OOMESTIC   ANO    FOREIGN 
COMMODITIES    EXPORTED    FROM    THE    UNITED 
STATES 

13 

BOOKING   NUMBER 

(SPEC:       TYPE'     AN              Hf/V»        1:    MAX- 
NUMBER    ASSIGNED    BY    THE    CARRIER    FOR    SPACE 
RESERVATION 

10) 

C        CANADIAN    FREIGHT    CLASSIFICATION 

E        COORDINATED   MOTOR    FREIGHT    CLASSIFICATION 

H        BRUSSELS    NOMENCLATURE    HARMONIZED   SYSTEM 

HARMONIZED   STNI 
M        MUTUALLY   DEFINED 
N        NATIONAL    MOTOR    FREIGHT    CLASSIFICATION 

REFERENCE   DESIGNATORIS):      Y301      YA01      '501 

<NMFC) 
S        STANOARO    INTERNATIONAL    TRAOE   CLASSI- 

Figure  4.10        Data  Dictionary. 
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associated  vith  the  data  segment  and  the  third  column  indi- 
cates whether  the  data  element  is  mandatory  (M)  ,  optional 
(0)  ,  or  conditional  (C)  .  Additional  information  is 
contained  in  the  remaining  columns.  These  tables  are  used 
in  conjunction  with  the  data  dictionary  which  describes 
individual  data  elements,  to  form  the  logical  schema. 

To  define  processing,  transactions  should  he 
defined.  Transactions  represent  events  in  the  real  world 
and  in  EDI  transaction  sets  represent  paperwork  which  docu- 
ment a  real  world  event.  Transaction  sets  are  defined  in 
terms  of  the  data  segments  from  which  they  are  built.  m  a 
sense  this  is  an  extension  of  the  logical  schema.  Figures 
4.13  and  figure  4.14  are  a  sample  of  two  EDI  tables  which 
list  transaction  sets  and  the  data  segments  they  include 
[Ref.  19].  In  Table  1  (figure  4.13)  the  transaction  set 
titled  "flight  confirmation"  is  assigned  set  ID  numter 
"10  1".  This  transaction  set  is  composed  of  eight  data 
segments.  These  data  segments  can  be  identified  using  Table 
2  (figure  4.14)  by  finding  the  set  title  "flight  confirma- 
tion" and  the  set  ID  number  "101".  The  second  column  under 
"flight  confirmation"  lists  each  data  segment  associated 
with  the  transaction  set  and  the  third  column  indicates 
whether  its  use  is  mandatory,  optional,  or  conditional. 
Additional  information  is  provided  in  the  remaining  columns. 

The  purpose  of  a  design  review  is  to  identify 
flaws.  Documentation  from  the  previous  stages  is  examined 
and  problems  are  identified  and  recommendations  for  resolu- 
tion are  made. 

2 •   Physical  Data  Ease  Design 

Since -EDI  is  not  a  data  base  management  system  as 
such,  the  steps  of  physical  data  base  design  apply  only  in  a 
loose  sense.  The  physical  design  differs  from  the  logical 
design  primarily  in  the  sense  that  the  physical  schema 
provides  for  the  implementation  of  the  logical  schema. 
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TABU  3  -  -SEGMENT  NAMES 


TABLE  3  -  SEGMENT  NAMES 


Segment  Nana 

CONTROL  HEADER  (FUNCTIONAL  GROUP) 

CONTROL  TRAILER  (FUNCTIONAL  GROUP) 

ENOING  SEGMENT  (TRANSACTION  SET) 

STARTING  SEGMENT  (UCS  TRANSACTION  SET) 

REJECTION 

BEGINNING  SEGMENT  FOR  MANIFEST 

BEGINNING  SEGMENT  FOR  BOOKING  OR  PICK-UP/DELI VERY 

BEGINNING  SEGMENT  FOR  SHIPMENT  INFORMATION  TRANSACTION 

BEGINNING  SEGMENT  FOR  CARRIERS  INVOICE 

BEGINNING  SEGMENT  FOR  INOUIRY  OR  REPLY 

BEGINNING  SEGMENT  FOR  ACCEPTANCE/REJECTION 

BEGINNING  SEGMENT  FOR  PAYERS  AUTHORIZATION 

BEGINNING  SEGMENT  FOR  COMPLETED  PAYMENTS 

BEGINNING  SEGMENT 

3EGINNING  SEGMENT  FOR  REPETITIVE  PATTERN  MAINTENANCE 

BEGINNING  SEGMENT  FOR  ADVANCE  CONSIST 

BEGINNING  SEGMENT  FOR  FILE  TRANSFER  INFORMATION 

BEGINNING  SEGMENT 

FREIGHT  PAYMENT 

COMPLETED  PAYMENTS 

BANK  ID 

CURRENCY 

COMMERCIAL  INVOICE  TOTAL  PRICING 

COMMERCIAL  INVOICE  CERTIFICATIONS  AND  CLAUSES 

CONSIGNEE  NAME 

CONSIGNEE  AOORESS 

CONSIGNEE  CITY 

CONSIGNEES  THIRD  PARTY 

CONSIGNEES  THIRD  PARTY  AODRESS 

CONSIGNEES  THIRD  PARTY  CITY 

DELIVERY  ROAD  CODE 

DESTINATION  STATION 

DOCUMENT  REFERENCES 

EMPTY  CAR  DISPOSITION  -  PENDED  DESTINATION  CONSIGNEE 

EMPTY  CAR  DISPOSITION  -  PENDED  DESTINATION  CITY 

EMPTY  CAR  DISPOSITION  -  PENDED  DESTINATION  ROUTE 

EMPTY  CAR  ADVANCE  DISPOSITION 

CAR  HANDLING  INFORMATION 

BLOCKING  AND  RESPONSE  INFORMATION 

EXCHANGE  RATE/ORDER  ACCEPTANCE  DATE 

CONSIGNOR  NAME 

CONSIGNOR  AODRESS 

CONSIGNOR  CITY 

CONSIGNORS  THIRD  PARTY 

CONSIGNORS  THIRD  PARTY  ADDRESS 

CONSIGNORS  THIRD  PARTY  CITY 

ORIGIN  STATION 

SHIPMENT  TYPE  INFORMATION 

BEYOND  ROUTING 

BROKERAGE  INFORMATION 

GOODS  DETAILS 

HAZARDOUS  MATERIAL 

ADDITIONAL  HAZARDOUS  MATERIAL  DESCRIPTION 

SPECIAL  HANDLING  INSTRUCTIONS 

CAR  SERVICE  ORDER 

INVOICE  TERMS  AND  CONDITIONS 

INVOICE  ITEM  LINE 

REMARKS 

ADMINISTRATIVE  MESSAGE 

FILE  INFORMATION 

LINE  ITEM  -  QUANTITY  AND  WEIGHT 

RATE  AND  CHARGES 

TARE  WEIGHT 

TOTAL  WEIGHT  AND  CHARGES 

MEASUREMENT 

DESCRIPTION.  MARKS  AND  NUMBERS 

CARRIERS  LINE  ITEM  REFERENCE  NUMBER 

TARIFF  REFERENCE 

LINE  ITEM  SUBTOTAL 

CHARGE  DETAIL 

LETTER  OF  CREDIT  REFERENCE 

INSURANCE 

SALES/DELIVERY  TERMS 

RELEASE 

CONSOLIDATION  MANIFEST  INFORMATION 

MANIFEST  LINE  IDENTIFICATION  DATA 

REPETITIVE  PATTERN  NUMBER 

SEAL  NUMBERS 


Sfltjrnerrt 

Data 

ID 

Elements 

(Table  4) 

XX 

5 

GE 

3 

SE 

2 

STR 

2 

A1 

4 

BO 

5 

B1 

3 

B2 

17 

S3 

1  1 

S4 

8 

B5 

4 

BG 

7 

B7 

3 

B8 

5 

B9 

8 

BA 

5 

BGF 

3 

BSG 

2 

CO 

4 

C1 

6 

C2 

7 

C3 

6 

C7 

3 

C8 

3 

D1 

4 

D2 

2 

D4 

5 

05 

4 

D6 

2 

D7 

4 

D8 

1 

D9 

4 

DR1 

e 

E1 

3 

E4 

4 

E5 

4 

E6 

a 

E7 

6 

EB 

2 

ERO 

3 

F1 

4 

F2 

2 

F4 

5 

F5 

4 

F6 

2 

F7 

4 

F9 

7 

G1 

3 

G2 

2 

G3 

3 

GDI 

10 

M1 
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Figure   4.11        List   of   Data   Segments. 
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TABLE  4      -DATA  ELEMENTS  IN  EACH  SEGMENT 


TABLE  4  -  DATA  ELEMENTS  IN  EACH  SEGMENT 


Segment 


Data 
Element 


XX 

142 

XX 

124 

XX 

29 

XX 

30 

XX 

28 

GE 

97 

GE 

96 

GE 

28 

SE 

96 

SE 

329 

STR 

143 
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A1 
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A1 
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A1 

44 

A1 

43 

BO 
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BO 
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BO 
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BO 
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BO 

91 

B1 

143 

B1 
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B1 
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B2 
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B2 
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B2 
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B2 
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B2 
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B2 

145 

B2 

188 

B2 

146 

B2 

160 

B2 

147 

B2 

11 

B2 

226 

B2 

195 

B2 

199 

B2 

57 

B2 

36 

B2 

460 

B3 

143 

B3 

76 

B3 

145 

B3 
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B3 
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B3 

12 

B3 
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B3 
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B3 
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B4 
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B4 
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B4 
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B4 
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B4 
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B4 
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B4 
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B5 
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B5 
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B5 
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B6 
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B6 
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Figure   4.12        Data   Elements   in   Each   Data   Segment. 
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TABLE  1  -  SET  NAMES 


Set  Nam 


Set 


FLIGHT  CONFIRMATION 

SHIPMENT  INFORMATION  (AIR) 

CONTAINER/EQUIPMENT  TRANSFER  (AIR) 

SHIPMENT  INFORMATION  FOR  EXPORT  DECLARATION  (AIR) 

SHIPMENT  INFORMATION  FOR  IMPORT  (AIR) 

SHIPMENT  INFORMATION  FOR  PICK-UP/DELIVERY  ORDER  (AIR) 

FREIGHT  DETAILS  AND  INVOICE  (AIR) 

FREIGHT  DETAILS  AND  INVOICE  SUMMARY  (AIR) 

INQUIRY  (AIR) 

SHIPMENT  IDENTITIES  AND  STATUS  REPLY  (AIR) 

STATUS  DETAILS  REPLY  (AIR) 

REPETITIVE  PATTERN  MAINTENANCE  (AIR) 

SHIPMENT  INFORMATION  (MOTOR) 

CONTAINER/EQUIPMENT  TRANSFER  (MOTOR) 

SHIPMENT  PICK-UP  ORDER  (MOTOR) 

SHIPMENT  INFORMATION  FOR  EXPORT  DECLARATION  (MOTOR) 

SHIPMENT  INFORMATION  FOR  IMPORT  (MOTOR) 

FREIGHT  DETAILS  AND  INVOICE  (MOTOR) 

FREIGHT  DETAILS  AND  INVOICE  SUMMARY  (MOTOR) 

INQUIRY  (MOTOR) 

SHIPMENT  IDENTITIES  AND  STATUS  REPLY  (MOTOR) 

REPETITIVE  PATTERN  MAINTENANCE  (MOTOR) 

RESERVATION  (BOOKING  REQUEST  -  OCEAN) 

CONFIRMATION  (OCEAN) 

CONTAINER/SPECIALIZED  EQUIPMENT  PICK-UP  ORDER/CANCELLATION 

CANCELLATION  (OCEAN) 

SHIPMENT  INFORMATION  (OCEAN) 

CONTAINER/EQUIPMENT  TRANSFER  (OCEAN) 

DOCK  RECEIPT 

SHIPMENT  INFORMATION  FOR  EXPORT  DECLARATION  (OCEAN) 

SHIPMENT  INFORMATION  FOR  IMPORT  (OCEAN) 

FREIGHT  DETAILS  AND  INVOICE  (OCEAN) 

ARRIVAL  NOTICE  (OCEAN) 

INQUIRY  (OCEAN) 

SHIPMENT  IDENTITIES  AND  STATUS  REPLY  (OCEAN) 

STATUS  DETAILS  REPLY  (OCEAN) 

REPETITIVE  PATTERN  MAINTENANCE  (OCEAN) 

SHIPMENT  INFORMATION  (RAIL) 

SHIPMENT  INFORMATION  FOR  EXPORT  DECLARATION  (RAIL) 

SHIPMENT  INFORMATION  FOR  IMPORT  (RAIL) 

FREIGHT  DETAILS  AND  INVOICE  (RAIL) 

FREIGHT  DETAILS  AND  INVOICE  SUMMARY  (RAIL) 

STATUS  INQUIRY  (RAIL) 

STATUS  INFORMATION  (RAIL) 

FLEET  REFERENCE  UPDATE 

REPETITIVE  PATTERN  MAINTENANCE  (RAIL) 

WAYBILL  INTERCHANGE  (RAIL) 

ADVANCE  INTERCHANGE  CONSIST 

EMPTY  CAR  ADVANCE  DISPOSITION 

CAR  HANDLING  INFORMATION 

COMMERCIAL  INVOICING  80O 

PAYMENT  AUTHORIZATION 

COMPLETED  PAYMENTS 

PAYMENT  ADVICE 

CONSOLIDATION  MANIFEST 

STATUS  INFORMATION  FROM  CONSOLIDATOR 

GENERALIZED  FEEDBACK 

ADVISORY  INFORMATION 

FILE  TRANSFER 

SET  CANCELLATION 

ACCEPTANCE/REJECTION  ADVICE 
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Figure  ft. 13   List  of  Transaction  Sets. 
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Figure  4.14    Data  Segments  in  Each  Transaction  Set 
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a.   output 

The  outputs  of  the  physical  design  are  the  phys- 
ical schema  and  the  definition  of  user  views.  The  physical 
schema  includes  specific  data  structures  (e.g.  linked  list 
or  inverted  lists)  and  the  necessary  algorithms  to  maintain 
and  manage  the  data  tase.  The  physical  schema  is  in  execu- 
table form.  The  definition  of  user  views  in  the  EDI  sense 
would  be  the  interface  software  which  would  link  a  unique 
data  rase  at  a  specific  command  to  the  EDI  standard  in  crder 
to  translate  the  data  for  transmission. 

3 .   Summary 

The  design  effort  required  to  implement  an  EDI 
interface  within  the  JJWMCCS  community  is  really  at  two 
levels.  At  the  joint  community  level  a  logical  design  must 
be  produced  by  the  users  and  a  physical  schema  by  the  appro- 
priate technical  experts.  At  the  command  level  software 
must  be  developed  to  interface  command  unique  data  bases  to 
the  EDI  standard  in  crder  to  enable  commands  to  successfully 
exchange   data   while    still  preserving   their    unique    systems. 
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V.  SUMMARY 

Cne  cf  the  major  problems  in  WWMCCS  ADP  today  is  the 
inability  tc  meet  tie  requirement  for  timely  exchange  of 
data  among  widely  separated  commands  in  a  time  sensitive 
environment  while  preserving  security  and  accuracy.  The 
current  method  is  to  have  commands  use  their  unique  applica- 
tions for  individual  processing  requirements  and  then  use 
one  of  a  few  standard  applications  in  order  to  interface 
with  ether  commands  in  a  form  which  can  be  interpreted  by 
them.  Ihis  method  entails  many  problems,  not  the  least  of 
which  is  a  requirement  for  manual  intervention  to  translate 
data  ameng  various  applications.  Manual  intervention 
increases  the  likelihood  of  problems  with  timeliness,  accu- 
racy, and  security. 

By  implementing  the  EDI  concept  the  members  of  the 
WWMCCS  community  could  substantially  reduce  these  problems 
by  reducing  the  requirement  for  special  interfaces  (manual 
or  automated)  between  each  set  of  applications  which  need  to 
exchange  data.  By  csing  the  EDI  concept,  any  command  which 
could  translate  to  and  from  the  EDI  standard  data  set  could 
exchange  data  with  any  other  participating  command. 

Figure  5.  1  shows  how  data  sets  are  exchanged  among 
commands  today.  each  dotted  line  represents  an  interface 
program  designed  to  "translate"  data  between  an  application 
at  one  command  and  an  application  at  another.  Today  if  MSC 
is  to  furnish  information  directly  to  three  applications  at 
other  commands  (e.g.  MTMC,  JDA,  MAC)  special  interface  soft- 
ware must  be  written  or  all  commands  must  be  restricted  to 
using  the  same  software  and  hardware.  In  addition,  if  any 
other  cemmands  needed  to  exchange  data,  they  would  need 
additional  software  to  facilitate  those  interfaces  (eg.  MTMC 
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and  JDA) .  Figure  5.2  Indicates  how  data  would  be  excnan^ed 
using  the  EEI  concept.  A  sample  data  exchange  using  data 
will  serve  to  further  illustrate  the  function  of  the  EDI 
standard   data  set. 


Figure   5.1        WWMCCS    Interfaces   Today, 


MSC        (2250061285) 


MAC     (650612)     .    .     .       EDI        (120635)       .     .     .    MTMC        (120665) 


Figure   5.2        Data   Exchange   Using   EDI. 


MSC  is  required  to  transmit  information  which  contains 
in  it  a  data  element  whicn  represents  a  date.  They 
transmit  this  information  to  JDA,  MTMC,  and  MAC.  Due  to 
their  unique  applications,  MSC  represents  this  date  as 
hour-minutes-month-cay-year    (eg.    2250061285). 

The  MSC-EDI  interface  translates  this  to  the  EDI  stan- 
dard for  date  which  is  expressed  (by  community 
agreement)    as    day-mcnth-y ear    (eg.    120685). 

The  EDI  software  packages  the  information  for  transmis- 
sion  and    sends  it    to   the    appropriate   commands. 
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When  the  data  is  received  at  JDA,  they  translate,  using 
command  software,  into  the  format  required  by  unique 
applications  at  JDA  (eg.  year-<-month-day  850612)  .  finen 
the  data  is  received  at  MTMC  it  is  used  in  the  EDI 
format. 

The  most  obvious  advantage  is  that  if  MTHC  also  interfaces 
with  JDA  nc  additional  interfaces  would  be  required  using 
the    EEI    concept. 

The  EDI  system  provides  for  the  transmission  of  the  data 
in  a  standard  format.  Each  command  provides  the  leans  of 
translating  their  data  to  to  and  from  the  standard  with 
command  unique  software.  This  does,  however,  reduce  the 
number  cf  required  interfaces  and  permits  reduction  of 
duplication  in  establishing  a  distributed  data  base 
approach.  Each  command  will  only  require  one  interface, 
regardless  of  the  total  number  of  commands  participating. 
Under  the  current  system,  if  each  command  is  to  exchange 
data  with  every  ether  participating  command  the  total  number 
of  interfaces  required  for  each  command  would  be  N- 1  (where 
N  represents  the  number  of  commands  participating) .  The  EDI 
standard  tables  could  contain  codes  indicating  which  command 
is  responsible  for  certain  kinds  of  transaction  sets  or  data 
segments  ard  to      whom   these    are   distributed.  In    addition, 

when  information  is  requested  through  the  EDI  interface,  the 
central  directory  would  have  the  means  to  locate  the  appro- 
priate command  from  which  to  draw  the  information.  This 
would  reduce  the  require  ment  for  each  command  to  maintain 
individual  data  directories  for  all  the  commands  with  which 
they  interface.  The  use  of  a  common  interface  permits  many 
widely  separated  data  bases  to  function  virtually  as  a 
distributed  data  base.  This  will  help  meet  the  identified 
requirement  for  a  distributed  data  base  approach  to  support 
JOPES.  It  is  not  a  distributed  data  base  in  the  routine 
sense  but  rather  an  interface  which  permits  the  exchange  of 
data   among   separate    data  bases. 
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The  EDI  concept  does  work.  It  is  being  used  is  the 
transportation  industry  today.  Figure  5.3  and  Figure  5.4 
are  provided  as  a  furtner  illustration  of  its  application 
[Ref.  21].  In  figure  5.3  the  sender  types  information  into 
a  terminal  in  the  format  required  by  the  individual  organi- 
zation (in  this  case  using  a  forms  mode  and  "filling  in  the 
blanks").  Figure  5.4  shows  how  the  same  data  appears  when 
it  has  teen  converted  into  EDI  standard  data  elements  and 
data    segments   by   means   of   the   table    driven    EDI  system. 

Use  of  the  EDI  concept  in  WtfMCCS  would  require  nigh 
level  support  and  commitment  throughout  the  joint  community. 
The  initial  effort  tc  develop  standard  data  sets  and  prepare 
command  interfaces  is  indeed  significant.  However,  since  it 
will  provide  the  capability  to  exchange  data  among  commands 
using  various  hardware,  software,  and  data  base  management 
systems,  it  has  the  obvious  advantage  of  providing  much 
needed  flexibiltiy.  Commands  would  be  able  to  utilize  state 
of  the  art  ADP  technology  tc  solve  their  unique  command  and 
control  ADP  requirements  without  sacrificing  the  capability 
to      exchange      data      effectively   with      other      commands.  3y 

providing  for  data  transfer  without  requiring  standarization 
and  duplication  cf  applications  and  data  bases,  EDI  supports 
more  efficient  use  cf  ADP  resources.  The  EDI  concept  can 
help  sove  the  data  exchange  problems  in  WWMCCS  ADP  today  and 
contribute  toward  fullfilment  of  evolving  requirements  for 
exchanging    data    among   commands. 
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(Sample) 
ABC  Company,   Inc.,   Anytown,   California 

elLI  TO:  IV.'CICi  N'jr,H:: 

i« i  es    ComD  - n  v  4-.  3S7Z2 1 

(iJCa     «     '-?  b  *'  a-i-r  _  —  x  '.".''.'^  ) 

Attn,     Accoun'Li nc    Dru I • 

i?S4     Hadiior    Ave. 

F i - eeffi d  j ntain.     C A    - -n  27  5 

Ec.ies.    Co.T.oan .  9034:7 

<L'C5    *    9876=^3210070) 
Grocer-,    WarsrsC'U.ss    *    70 
22    west    LofiO    =t. 

r  j.  Ct  '■  1  iRCi  .       CA      '-43'.".' 

in.:::e  date: 

la    Get     19S2 


27.    10    Net    30 

Slh:.:::v  ub:t    up:  vekk?  l*kit  d£3;f:=t:ck  list    unTt    satzmick 

Njr.sE?.  Fr.:f  i  i::e  ;:=:  Al.d«. 


10   CS  0037 13V1 234 i  24 .'  ,  d  2Z   ABC  Tree!  rru!:i  E&I  sd   13.17     131.70 

1   23  0037 13V 1274 5  24/lc  27   AfiC  Trocl  Fruit  Salsd      NC       0.00 

30   C2  0037  i3?o7ST-'C  24/2  01         ABC  Cut  bren?r>    Beans      9.76     2?2.  bO 


TOTAL.:  £42-;.  20 


SFEJIE.  IN37RU2TICr;2: 


C3NTACT: 


Figure  5.3   Transmission  as  Submitted. 
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TRANSACTION  SET  EXAMPLE  -   INVOICE  *  44887221 


(BG  SEGMENT) 
(GS  SEGMENT) 


ST»880» 

GO  1  »82 1 0 1 6*4488722  1  *820928»9034 1 7 

LS*O1O0 

M  i»BT— 9*98765432  1 0002 

N 1  *ST*SALES  COMP  ANY»9*98765432  10070 

N2-GR0CERY  WAREHOUSE  *   70 

N3»22  WEST  LONG  ST 

N4»RICHLAND»CA«94800 

N 1  »BY»*9*98765432 1 000 1 

N1»SU*ABC  COMPANY.  INC  «9»  1 23456789000  1 

LE*0 1 00 

LS-0200 

G17*1  '.»CA*1 3 1700*0037 139 12345 

G69-ABC  TRPCL  FRUIT  SALAD 

G20*24»1600*OZ 

LS-0210 

G72*  1  «02*»-  1 3 1 700****  1 000»CA 

LE*02 1 0 

G 1 7«30*CA»97600»0037 1 3967890 

G69*ABC  CUT  GREEN  BEANS 

G20*24»800*OZ 

Uz-0200 

G23*0 1*3*2000** 1 0*«30 

G25»PB»03 

G31"41*CA 

G33*42450*41601 

SE*27* 

(GE  SEGMENT) 
(EG  SEGMENT) 


Figure  5-1       Transmission  in   EDI   Format 
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